Fixes the one definitely lost shape from the original valgrind report (the "possibly lost" shapes are the well-known glibc/Qt TLS false-positive pattern and aren't touched here).

The leak: CJamController::SetRecordingDir() (src/recorder/jamcontroller.cpp) unconditionally does pJamRecorder = new CJamRecorder(...), then calls Init(). The moveToThread + deleteLater cleanup wiring only happens inside the if (bRecorderInitialised) branch below it. If Init() fails — e.g. an unwritable recording directory — the freshly-new'd object has no parent, no thread affinity, and nothing connected to deleteLater. CJamController has no destructor, and CJamRecorder's own constructor takes no parent, so nothing else ever frees it. The next call to SetRecordingDir() overwrites pJamRecorder, so the leak repeats on every failed directory change.

The fix: delete it immediately in the failure branch, right where bRecorderInitialised is set. It's provably safe to delete unconditionally here — this object is only reachable via the local pJamRecorder pointer at this point, never moved to a thread, never connected to anything. (The other branch, further down — a running recorder switching to an empty dir — is a different object already scheduled via deleteLater; deleting there would double-free, so the fix is scoped only to this one failure path.)

        if ( !bRecorderInitialised )
        {
            delete pJamRecorder;   // Init() failed: never moved to thread / never
            pJamRecorder = nullptr;//   wired to deleteLater, so free it here (#1083)
        }

Verification: built headless/serveronly locally (qmake CONFIG+=headless CONFIG+=serveronly && make), clean compile, binary runs. I don't have a way to re-run the original valgrind report here, but the fix is small enough to review by inspection — happy to add a regression test if maintainers want one (e.g. drive SetRecordingDir with an unwritable path and assert no CJamRecorder outlives the call).

Fixes #1083.